Hi，大家好，今天是第3天，昨天我們簡單的列出了平台、架構、資料庫的相關選項，並決定了你講我忘報單系統的使用平台和資料庫，今天繼續來進行分析的第二階段。

關於分析工具，這次我要使用UML的使用案例（use case diagram）和活動圖（activity diagram），前者可以快速的看出系統的使用對向與各自可執行的功能，後者可以當作流程圖來使用，當然在這裡補充一下，不是說其他的class diagram、sequence diagram…等不重要、只是相比前2項，我平常用的比較少罷了

use case diagram

上圖是目前規劃UseCase，一般的 UseCase，人的符號代表使用者，橢圓形則是可執行的功能，UseCase最大的好處是可以一眼就看出系統的功能與系統的使用者種類有哪些？通常我會和心智圖搭配，先在心智上列出所有想法，最後再列成UseCase的圖形。
由上圖可知，本次的系統中設定了4種不同的使用者種類，且各使用者可執行的功能如下表所示

activity diagram

活動圖（activity diagram）其實就是計算機概論學的標準流程圖的變形，但是不管怎麼變，其實原理相同，黑色實圈為起點，雙圈為終點，中間圓角矩形為一個一個的活動，若有判斷需求，則畫一個菱形加上判斷式與箭頭方向。在繪製時，理想作法為每個UserCase 的項目，至少要有1個以上的活動圖（視活動大小說不定要拆分2個以上），但是大部份是能省則省就是了XDDD

我其實是仿照我所知的ISMS服務台機制去規劃這個流程的，該機制主要的問題是由使用候或服務台登記問題後，先行通知使用者已收件後，再由服務台（其實通常是一線客服主管）判斷是否需要後送或是服務台可以直接處理，若服務台可直接處理，則回報處理結果並結案，若需要後送，則成立問題單後進行處理動作並通知使用者已排入處理流程，並提供使用者案件編號以供查詢之用。待處理程序完畢後，再另行通知結案，實際上要過一些查核點，這次做的是簡化版，工程師說好了就好了XDDDD。

這個流程是簡化過後的流程，反正就是登入系統後，紀錄已經完成修改就可以進行結案了（實際上的流程超囉嗦，還要準備表單和佐證資料的，只能說晚上早點睡，夢裡什麼都有XDDDD）

這個是最簡單的，登入後輸入查詢條件或是統計區間，就可以看到結果

結論

這次以使用案例（use case diagram）規劃系統預訂功能與使用者種類，並活動圖（activity diagram）畫出初步流程，已經可以稍微窺伺系統的全貌了，明天的計畫是資料庫分析，接下來就是寫code了，敬請各位不抱期待的看下去啦XDDD！

題外話

畫活動圖雖然簡單，實際應用若是有繪製的習慣，至少可以避免後續開發時做出來歪掉的東西，我個人覺得，就算是純前端也應該學一下，畢竟活動圖的範圍其實不限於使用案例的單一項目，針對單一網頁的操作畫出活動圖後並共享給整個團隊，真的可以排除掉上面的頭頭想要的是一回事，下面做出來的東西整個走鐘的情形，反正有問題大家拿活動圖出來對完，有問題打上一架就行了XDDDD